home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 4504 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.3 KB
  1. Path: soap.news.pipex.net!pipex!usenet
  2. From: m.hendry@dial.pipex.com (Mathew Hendry)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: 680X0 -> PPC translator?
  5. Date: Thu, 29 Feb 96 19:28:51
  6. Organization: Private node.
  7. Distribution: world
  8. Message-ID: <19960229.43A058.11BCF@am090.du.pipex.com>
  9. References: <4h4fk6$f7a@maze.ruca.ua.ac.be>
  10. NNTP-Posting-Host: am090.du.pipex.com
  11. X-Newsreader: TIN [AMIGA 1.3 950726BETA PL0]
  12.  
  13. Sara Geerens (sgeerens@zorro.ruca.ua.ac.be) wrote:
  14. : Isn't code from compilers somewhat structured enough? Only pretty messy 
  15. : compilers make messy code... and using complicated code to test between data 
  16. : and code can be done.
  17.  
  18. Not realistically. There is no way to accurately determine whether a
  19. particular part of a program is code or data without actually running it - and
  20. running it exhaustively. Most compilers _do_ misplace code and data within the
  21. hunk structure, either to take advantage of the speedups available if you use
  22. near data, or simply due to design faults. A lot of programs also include
  23. hand-tooled assembly language, whether to provide speedups, or to provide
  24. functions difficult or impossible to implement well in compiled code. These
  25. assembly language fragments are much more likely than compiled code to
  26. misplace code and data in the hunks.
  27.  
  28. :                       Maybe you could track every trace it can follow...
  29. : translation doesn't have to be fast...it only has to run fast... :-)
  30.  
  31. The time taken to track every path a program can take increases exponentially
  32. with the complexity of the program and the data it uses. With large programs
  33. you could never track every possible path within your lifetime - there are
  34. just too many combinations.
  35.  
  36. By the time it's finished, the program would be obsolete anyway, probably by
  37. millions of years ;)
  38.  
  39. The best method would appear to be on the fly emulation, with online caching
  40. and subsequent storage of any translated code. In other words, the user would
  41. be deciding which particular program paths to take, and perhaps translating
  42. new parts of the program each time it is run.
  43.  
  44. Managing the storage of the translated code would be complicated, though -
  45. it's likely that a simple emulator would appear first, with the more advanced
  46. features coming later. This if only for the reason that the emulator would
  47. have to be very reliable before attempting to add such features.
  48.  
  49. -- Mat.
  50.